*0158*At the top of the Application Builder System Class Hierarchy is the System class*1037*. This abstract class (refer to “Challenge: Abstract Classes” in chapter 6 for more on abstract*17* classes) functions as a convenient means to provide three key attributes to all other System classes. By way of inheritance, the*1043* name, owner,*1044* and active? attributes become the first three listed attributes in all System class-hierarchy subclasses.
 
The name attribute allows all instances of System classes to be referenced by a name. The default value of the name attribute is an empty string of character-type data. By setting this attribute, for example to “Inventory list,” a Scroll List instance can be accessed by its more meaningful, application-specific name. Thus a find-item operation looking for a scroll list called “Inventory list” makes more sense than a get-nth operation looking for the nth item in a Window instance. Access by name also avoids such nth-access errors when the item list attribute of a Window or Menu instance is reordered.
The owner attribute is optionally set to the logical object that “owns” the instance. In this context, Window and Menu instances can be owned by an Application instance, and Button and Edit Text instances can be owned by the Window instance in which these Window Item subclass instances appear.
The active? attribute*1042* is a default boolean data value that is set and read to determine whether an instance is active or not. The meaning of an item’s activity status is related to the object’s behavior. An active Window instance is visible. An active Edit Text item shows a blinking insertion bar and is ready to accept keyboard input. An inactive Menu Item is dimmed and unselectable.
As an abstract class, instances of the System class should not be generated. Nothing bad happens if you create a System object—it is simply a rather useless object.
NOTE: Application Builder’s System classes*1038* are all subclasses of the System class. As explained, this is for the convenience of inheriting three generally useful attributes. You are not required to create user-defined classes as subclasses of the System Class Hierarchy.
Prograph supports multiple class hierarchies*0154* within a single operating environment. The criteria for making a new class as a subclass is based on*479* inheritance considerations. If your new class could use some or all of the attributes and methods of a class, create the new class as a subclass of an existing class. If the new class is unique, simply create it without connecting subclass inheritance links.
The Application Class and Its Instances
*59*A good starting place for understanding Prograph applications is to understand the Application class. As you might expect in an object-oriented environment, your Prograph applications are instances of class Application. The Application class defines a type of object that consists of two shared class attributes and eleven instance-specific attributes.
u Make sure your application is not running.
u Open the Application Attribute window and scroll through its graphical list of class and instance attributes.
You see that the default values of the Application class and instance attributes are empty strings, NULL values, and empty lists. But notice the current class attribute. The current class attribute holds an instance of class Application, the application that runs when you switch context.
The relationship between the Application class and its class attribute current is similar to that between the Barnyard class and its activeYards class attribute in the Barnyard Simulation example in chapter 6, “Language Basics: Classes.” Both class attributes store instances of their classes.
Your NewWin window is a window within the Application instance stored in current. To locate and inspect your NewWin window instance:
u Double-click the current class attribute icon to open a Value window on the Application instance stored within this attribute. Scroll around the Value window and notice the specific values that are assigned to the various attributes of this Application instance. If you are working on a large-screen monitor, such as Apple’s 13" color monitor, you can resize your windows so you see the attribute definition of the Application class and the Value of Attribute current window, like this:
 
You can immediately start to make a connection between the raw attribute value display of the Value of Attribute current window and the edit fields of the Application Builder’s Application editor.
u Click the Graphic check box in the Value of Attribute current window. Up pops the Application editor, which you have previously accessed from the Edit Application menu selection.
u In the Application editor you see the string, Test Windows, in the Name edit text field. Dismiss the Application editor and notice that the name attribute of the Application instance stored in current is the string Test Windows.
NOTE: You can think of the Application Builder*57* editors as the “forms-view” data entry component of a database-management system in which the database records are instances of Prograph System classes.
The edit-text fields in the various Application Builder editors correspond to attributes in the System class for which each editor is named. Other components of these editors manage additional attributes of the System classes. For example, when the Windows and Active List radio buttons are highlighted in the Application editor, the Instances scroll list is the list of Window class instances that are stored in the windows attribute of the current Application instance.
The sooner you make a clear connection between the fields and lists of Application Builder’s editors, and the underlying attributes of the System classes, the better you will understand what you are doing as you develop increasingly complex applications.
u To make the connection between the current Application instance’s attributes and the Application editor even more clear, notice that the*61* about method in the Value of Attribute current *62*window is set to /About.
u Click the Graphic check box, and note that the About Method field in the Application editor is also set to /About.
As you can see, Application Builder’s editors provide a convenient means to edit the attributes of System class instances. Where then, you might wonder, is the NewWin window?
u Look at the last four items in the scrolling list of attributes in the Value of Attribute current window. The menus and menu lib (library) lists each contain one item, the File menu that comes as a standard part of System Classes.
u A Window class instance, «Window», appears in the window lib attribute. Double-click the window lib attribute icon to open a Value window, and then double-click the single Window instance icon that appears in the graphic pane of the window lib list. Now click the Graphic check box in the Value of List Item 1 window to see the NewWin window, which is described by the attribute values in the Value window.
 
In fact, if you compare the NewWin attribute values with the input and output values of the NewWindow operation in the earlier Do-It-Yourself Window example, you see additional parallels. The string “NewWin” was the third input to NewWindow. The “8,” which is the Macintosh identifier for a document window, was the fifth input to NewWindow and is the value set for the def ID attribute of the NewWin instance. And the output of the NewWindow operation was a Macintosh window record. You can find that Macintosh data structure stored in the attribute, window record.
Making this mental connection between Prograph’s System classes and the underlying Macintosh system implementation of these interface elements is important. But what is exciting is that so much of this complexity comfortably remains below the surface. You don’t have to deal explicitly with most of these implementation details.
Recall how easy it was to create the NewWin window in a what-you-see-is-what-you -get (WYSIWYG) manner. The ease with which you created this window is carried over into the menu editor and the various window-item editors included in Application Builder. Prograph knows and manages the correct Macintosh *561*Toolbox calls and operating-system facilities required to implement these interface elements. You keep your sights on the higher plane of your application design and interface behavior.
Of the ten noninherited attributes of the Application class, four are key to organizing and implementing the interface of your application. Before discussing these four key attributes, consider briefly the function of the other attributes.
Of the two class attributes, you already have a sense of the function of the current attribute—the Application instance stored in current is the one that Prograph calls when its automatic event-loop processing is initiated as you switch context.
The*63* front class attribute is set with the topmost, active Window instance—the window in front of any others open at the time. The front attribute always shows a NULL value when you inspect the Application attributes window anytime the application is not running. If you interrupt execution and inspect the Application class attributes, you find front set to whichever Window instance is active at the time of the interruption. A Get operation on front is a convenient way to find out which window is active when a user-interaction event takes place.
Of the noninherited instance attributes of Application, two—menu bar and resources—are rarely accessed directly. These attributes are set to Macintosh memory identifiers. Fortunately, you can write sophisticated Macintosh applications in Prograph without knowing about such complicated topics as blocks, handles, pointers, resource identifiers, and file reference numbers. These attributes hold very technical information and are used almost exclusively by Prograph, not by you directly. Of course, they are there for you to access if you know what they are and how to use them.
The about method attribute is set to the name of the method that is executed when the user selects the About… item in the Apple menu while your application is running. The simplest about method is one that feeds a string with application and author-identification information into a show operation. Of course, an about method can be as elaborate as any method can be in Prograph, accessing external resources and using graphics, and so on.
The big four attributes, however, of the*60* Application class are windows, menus, window lib, and menu lib. Diagrammatically, a sample application might look like this:
 
The application represented by the above diagram looks like this when running:
 
Its Application editor displays are:
 
Notice that the windows and menus attribute*64**65* values are subsets of their respective library attributes*66*. That is, Window A is an active, visible window. Therefore, this window instance is added to the list of Window instances set in the windows attribute list. Window A, however, is also found as an item in the window lib attribute list.
NOTE: How can an object be in two places at once? Well, an object is really a data structure residing somewhere—say address #A001—in RAM. When you add this object to a list in Prograph, the physical object is not in the list—the list simply knows what objects are members of the list and maintains pointers to its members.
The same object can be a member of a number of lists. For example, if List A knows it has an object at address #A001 and List B also knows it has a member that can be found at address #A001, then if you access the object at #A001 from List A and change an attribute value of that object, when you access the #A001 object from List B, it reflects the change. This is an important concept to understand, as it initially seems counter-intuitive to the concrete “objectness” of an object-oriented language. The objects are “concrete” in their memory*769* locations. You can, however, get at them from a variety of views—like coming into a room from four different doors.
When the active? attribute of an active Window or Menu instance is set to FALSE, the instance is removed from the list of the windows or menus attribute. The instance remains in the window lib or menu lib attribute list so it can be easily reactivated. Without the library lists to point at inactive windows and menus, RAM would quickly become cluttered with multiple copies of such items. You would have a hard time finding existing instances of these classes and so would create a new one any time you needed to display a window or menu. The window and menu *508**509*libraries are resource pools of already created objects.
NOTE: Application Builder’s*44* Application editor coordinates instance creation and updating of both the library and active lists of your application. You are strongly encouraged to use the Application editor to create, delete, and update Window and Menu instances.
Take a few minutes to explore the Application editor.
u Create a few example Window and Menu instances, as above, and experiment with adding and deleting them from the Active List and Library.
u When you have an application setup that includes a few active and some dormant windows and menus, run your application.
u Switch context to pause the application and open a Value window on the current attribute of the Application class. Inspect the various attributes and try editing their values. (Don’t forget to try clicking the Graphic check box, when it is enabled, in the Value window of the attributes you inspect. Notice how it works when you inspect the cursor attribute.)
*67**68*Some attributes can be set—their values can be changed—while the Application instance is active. Other attributes are protected and cannot be set while the application is active. Of the attributes that cannot be set, some—like menu bar—cannot be edited even when the application is not active. Others, like windows and menus, can be set when the Application instance is inactive.
An important objective of this exploration is to understand that, while you are given great freedom to inspect and edit critical objects and data values that make up your application, Prograph protects you from making simple Value window edits that would “blow up” or “crash” your system.
Of Menus, Windows, and Their Items
The bulk of the System Class*674* Hierarchy*1047* consists of the Menu, Menu Item, Window, Window Item,*1166* and Window Item subclasses. As you have seen, Menu and Window instances are owned by an Application instance and are stored in its four key lists.
The Menu Item class*1052* and the various Window Item subclasses define objects that can appear in Menu and Window instances, respectively. Menu Item instances are the selections that drop down from the menu bar when you click on a Menu name. Window Item instances are the objects that appear in a window. Menu and Window Item instances are stored in the item list attributes of Menu and Window classes, respectively.
Extending the diagram showing the relationship of the items that make up a Window and Menu instance within an example application, you see that Window Item and Menu Item instances are found in the item list attributes of the objects that own them.
 
The example application diagramed above looks like this when executed.
 
If you are fairly experienced running your Macintosh, you won’t have any trouble figuring out the function of the various attributes in the Menu Item class and Window Item subclasses. The*83* active? attribute*18* determines whether a Menu Item, Button, or Radio Set—among others—is functional or dimmed. The TRUE or FALSE state of the check? attribute of a Menu Item instance determines if a check mark appears before the item’s name in a pull-down menu. The boolean valued*1147* visible? *86*attribute of an Icon instance determines whether it is seen in its window or not.
The*939* Reference *938*manual contains a comprehensive specification of the System Class Hierarchy. Attribute names, their function and allowable values are included for each class in the system. In addition, the Application Builder-oriented Grand Tour chapter (chapter 3) provides hands-on experience in creating and manipulating windows, menus, and their contained objects. But before you launch out on your own, take a few minutes here to think about the way in which you work as you develop an application and about how Prograph can enhance your development style.
